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ABSTBACT 






This thesis examines the structure and functions of a 
generalized tactical intelligence collection system. 
Included are its position in the intelligence system struc- 
ture, relationship with other activities in the intelligence 
system, and the organization and control of its components. 
A mathematical optimization model of a simplified intelli- 
gence collection system is developed to explore several 
issues related to intelligence collection. An interactive 
multiattribute decision aid useful in the prioritization of 
numerous intelligence collection requirements is 
demonstrated. 
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I. IN TBODOCTION 



A great deal of effort has been expended in c ecent years 
concerning the management of large quantities of battlefield 
intelligence information. The presumption of such concern 
is that vast amounts cf information will be collected during 
the ccurse of the future battle. The deployment of numerous 
collection platforms, sensors, and the like does suggest 
that there will indeed be a deluge of information. Eut will 
this information be cf value to the decision maker? 

Cne way to insure that collected information is of value 
is to manage those collection platforms in an intelligent 
manner. This implies that their operation should be ccntro- 
lable and efficient. This thesis will develop the physical 
and functional structure of a generalized intelligence 
collection system with the idea in mind of improving the 
control and efficiency of its collection platforms. It will 
analyze the components of this collection system to deter- 
mine where modern management tools can be applied to the 
collection management process. 

Chapter Two introduces the generalized intelligence 
system structure and describes the relationships between its 
major subsystems - the requirements system, analysis system, 
collection system, and dissemination system. It addition- 
ally highlights the role the intelligence requirement plays 
in the intelligence system. Chapter Three focuses upon the 
intelligence collection system to include its structure, 
functions, and considerations which make the effective 
management of the system such a difficult task. Chapter 
Four analyzes the critical component of the collection 
system - the intelligence collection requirement - in great 
detail. It focuses upon the sources of the collection 
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require meet and the traditional flow and management cf the 
requirement in the collection system. Chapter Four addi- 
tionally developes a more analytical manner in which collec- 
tion requirements car be decomposed into smaller elements 
and, based upon this process, suggests a restructuring of 
the traditional collection system. Chapter Five develops a 
mathematical optimization model of the collection management 
process and explores variations of that model which are 
useful in the understanding of the collection management 
problem. Chapter Six illustrates how the models developed 
in the previous chapter can easily be modified to the real- 
istic collection management environment. Finally, Appendix 
A demonstrates a multiattribute decision making approach 
toward the prioritization of collection requirements 
according to current or envisioned battlefield conditions. 



II. A generalized inte llig ence system 
A. I BTRCD OCTION 

Any tactical intelligence system can be described in 
terms of its major functional systems. These systems 
include the following: 

- Eeguirements System 

- Analytical System 

- Collection System 

- Dissemination System 




Figure 2. 1 Generalized Intelligence System. 

The focus of this chapter will be to examine seme of the 
generalized characteristics of the first two of the systems 
listed above. Because of its key role in the collection and 
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analytical process, particular attention will be paid tc the 
generalized requirements system. A detailed anaL ysis of the 
collection process and system will follow in the remaining 
chapters of this study. Therefore only fundamental consid- 
erations of that process as it relates to the analytical and 
requirements systems will be addressed in this section. The 
analytical system, though critically important to the 
overall intelligence process, will only be addressed as it 
relates to a collection system - the primary subject of the 
thesis. The dissemination system will not be specifically 
addressed due to its relationship and identification with 
the type of communication system employed by the intelli- 
gence system. The ether two systems, however, are more 
easily isolated from the specific aspects of the communica- 
tion sytem and will he discussed. 

Figure 2.1 depicts the functional relationships formed 
between the three major components of a tactical intelli- 
gence system. Intelligence requirements are generated by 
the users of the system - subordinate units, staff elements, 
and tie c^imander. These requirements can be satisfied in 
one of three ways - through analysis, collection, or a 
combination of the two. The requirements and analysis 
systems both task the collection system for intelligence 
information. The collection system primarily responds to 
such tasking and rarely would task the other two systems for 
substanitive information. 

The following paragraphs will address topics related to 
this general structure and its functions in a more detailed 
manner. 

E. eicoihements SYSTIH 

A requirements system must be able to accomplish three 
basic tasks: 

- Receive intelligence requirements from users. 



13 



- Identify the nature of the requirement with respect to 
the capabilities of the particular intelligence system. 

- Task the proper functional subsystem (s) of the intel- 
ligence system for satisfaction of that requirement. 

The first of these requirements is not related to the topic 
of this thesis. The other two, however, are more inter- 
esting and and will be addressed. It is importaa t, prior to 
beginning this discussion, to first understand the complex 
nature of an intelligence requirement. 

An intelligence requirement is a representation cf a 
user’s need for information concerning the disposition, 
capabilities and intentions of his enemy. Clearly, this 
definition is quite broad and necessarily subjective in 
nature. More specific definitions of an intelligence 
requirement are difficult to express. Enumeration of all 
previously identified and envisioned requirements is imprac- 
tical {and probably impossible). It is possible, however, 
to classify intelligence requirements into functional 
categories. This classification scheme will eventually 
allow for a more precise representation of an intelligence 
requirement. 

C. TEE CLASSIFICATIC3 OF I NTEILIGENCE BEQ0IREME3JTS 
1 . acq uir em ents as a F unc tion of Obje ctive 

Every intelligence requirement has an objective. 
For the most part that objective is to determine or clarify 
some enemy related characteristic which at the present time 
is not satisfactorily defined. The requirement objective 
may be related to enemy capabilities. This, in turn is 
related to the type of enemy force or concern - armor, 
artillery, chemical, air defense, etc. A requirement objec- 
tive may also be related to enemy disposition. In this case 
concern would be directed toward the spatial orientation of 
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enemy units on the battlefield. Targeting information, for 
example, forms a class of intelligence requirements -whose 
objective is related to enemy disposition. Requirements 
related to first or second echelon forces are also disposi- 
tion oriented. Other requirement objectives are related to 
enemy intentions. These requirements are generally more 
subjective in nature and, hence, their eventual satisfaction 
depends upon an understanding of enemy tactics and doctrine. 

The point tc be made is that an objective is one 
factor which all intelligence requirements have in common. 
Although it may be impossible to enumerate all possible 
requirement objectives, it is possible to relate each 
requirement objective to either the analysis or collection 
activities. This capability is important and will allow for 
a greater development of an intelligence collection model in 
this thesis. 

2. Req uir em ent s as a Function of Time 
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3. Par tia lly Sa tisfie d Requir ement s . 

Seme requirements may, after a first effort by the 
intelligence system, be only partially satisfied. In this 
situation the following points must be considered: 

a. Extent of User Satisfaction 

The extent of the user satisfaction/ 
dissatisfaction with the partially satisfied intelligence 
requirement is important for two reasons. The most impor- 
tant is that of determining whether or not the requirement 
should be replaced into the system. If the level of dissat- 
isfaction was absolute then it might be wise to consider 
resubmission. However, if the dissatisfaction was less 
severe, then resubmission of the requirement may be unwise. 
The second reason this consideration is important deals with 
improvement of the requirements system. Any system must 
know when its performance is unsatisfactory if it is to have 
any chance of long range success. Information concerning 
the extent of user satisfaction therefore is useful in that 
it provides the collection system operator with feedback 
concerning the performance of his system. 

The existence of partially satisfied require- 
ments in the intelligence system suggests that some proce- 
dure for reinsertion cf these requirements should (if that 
action seems suitable) exist. At a minimum an analyst 
should be aware of the existence of such requirements and 
consider their impact on the intelligence process and 
methods of dealing with that impact. 

b. Requirement Validity 

The requirement may or may no longer be valid. 
For instance, the initial informational requirement may be 
such that delayed or subsequent satisfaction would be of 
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little or nc use to the user. In this situation it would 
not be wise to resubmit the requirement into the system for 
satis faction. 



c. Partial Requirement Validity 

The requirement may be partially satisfied and 
therefore only partially valid. In the event some version 
of the original demand still exists, then that subset of the 
original demand (or requirement) might be replaced into the 
intelligence system for further action. 

4 . Main tenanc e Req uir e ments 



Seme requirements are generated by the intelligence 
system itself. These can be thought of as overhead costs 
which must be expended to maintain the system. These 
requirements are sometimes referred to as collection or 
analytical management requirements. 

5. Pri orit y of Re quir e ments 
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describe and is bandied best when broken down in a bit acre 
detailed manner. 

Ihe previous discussion leads to the following func- 
tional representation of an intelligence requirement. It 
can be defined in terms of its relationship with objective, 
time, and priority. 



Requirement 



f ( objective, time 



priority ) 



(egn 2.1) 



Maintenance requirements are treated as a special subset of 
the generalized intelligence requirement and partially 
satisfied requirements are treated as scaled down versions 
of regular intelligence requirements. 

E. FOHCTIGNS OF A fi ECUIEEM ENTS SYSTEM 

Based upon this brief introduction to the types of 
requirements which are associated with a tactical intelli- 
gence system it is new possible to address the functions a 
requirements system must perform. Figure 2.2 is a func- 
tional schematic of a generalized requirements system. Ihe 
discussion which follows addresses each major portion of 
this system. 

1. Definition and Cate qor i zati on of Requirements 

In this section of the requirements process general 
intelligence requirements which enter the system frem users 
are mere clearly defined. In particular, the objective of 
the requirement is clearly outlined. Additionally, the 
justification for the intelligence information should also 
be determined at this time. From this clarification process 
each intelligence requirement can be categorized according 
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Coll tctf on 
toqufr«a«Tt 



Figure 2.2 Requirements Process. 

to each functional parameter mentioned in the preceeding 
discussion. These are addressed below: 

a. Requirement Objective 

The objective of the requirement should be 
specifically determined. Not only should the najor objec- 
tive classi fication (disposition, capanility, or intention) 
be identified but also any identifiable subclassi ficaticns 
which might provide insight into the nature of the objec- 
tive. Examples of such sub classif ica tions include the ulti- 
mate use of the intelligence information (operations, 
terrain analysis, targeting), the types of enemy forces the 
user is most interested in, etc. The ultimate purpose of 
this section is to provide as much information as possible 
to the intelligence system concerning the nature of the 
requirement objective. 
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b. Time 
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Once the intelligence requirement 
fined with respect to the parameters disc 
would, under normal circumstances, progre 
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Requiremen t) 



A filtering process must basically accomplish two 
functions. It should determine if the requirement can be 
satisfied with information already on hand or is being 
worked on by the system even though the information may not 
actually be on hand. If so, then the normal procedure would 
seem to be to immediately provide the user with the appro- 
priate information. The implications of this seemingly 
simple transaction are great. It implies that there is (or 
should be) an effective interface (information access) 
between the requirement filtering process and the primary 
intelligence data base. If the requirement can be satisfied 
with information already on hand then it would seem reason- 
able to forward that information to the appropriate users. 

It should also determine whether or not a require- 
ment which cannot be satisfied with on hand information will 
be satisfied (and at what level of effort) through tasking 
of the intelligence system. This is the heart of the prior- 
itization process and as such can become quite complex. 
Requirement prioritization is basically a function of some 
of the following factors: 
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a. Command Guidance 

Obviously this is the most important input into 
the filtering process. It is expected (and experience 
shows) that this guidance is fairly general in nature and 
for the most part follows the dictates of current plans and 
operations. More specifically/ we can expect the commander 
to be concerned that friendly units involved (or soon to be 
involved) in combat operations receive the proper amount and 
guality of intelligence support. He would also be concerned 
that all significant threats to the well being of his unit 
are identified and understood. When intelligence resources 
are scarce the commander’s guidance also serves in an impor- 
tant de facto resource allocation role. 

It should also be noted that as any combat situ- 
ation changes the nature of command guidance might very well 
change. This consideration indicates a need for an intelli- 
gence system to be flexible enough to respond to any envi- 
sioned changes in command guidance. 

t. Criticality of the Requirement 

Certain types of intelligence will almost always 
be of greater importarce to the unit than others. Normally/ 
these types of information are of potentially great threat 
to the unit or of extreme importance to the outcome of the 
unit’s mission. An example of high threat information might 
he that related to the enemy's current capability to deliver 
nuclear weapons. Information of high importance might be 
that related to the enemy's command and control structure. 
It should be noted that the potential importance cf a 
requirement could easily be described as a dynamic process 
with respect to the conduct of the battle. For example, 
intelligence concerning a nuclear capable missile with a 
range of 100 kilometers becomes more and more important as 
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that missile moves from rear areas to forward positrons or. 
the battlefield. 

c. Answerability of the Requirement 

Some requirements simply cannot be addressed by 
the system. A time sensitive (i.e. the information is 
needed quickly) yet legitimate requirement (legitimate in 
the sense that the system under normal circumstance would 
and cculd respond to such a requirement) may be unanswerable 
due to the limitations of the intelligence system itself. 
Similarly, an overly detailed requirement may also be beyond 
the capabilities of the system. The following intelligence 
system responses to this type of requirement can be 
envisioned. 

- Reject the requirement outright. 

- Pass the requirement forward to higher or lower units 
for possible satisfaction. 

- Negotiate the specifics of the requirement with the 
user to determine if one or more of the restraints can 
be relaxed. 



d. Quantity cf Users 

The stresses on the system, both from a manage- 
ment and resource allocation point of view, increase with 
the presence of more users in the system. It is expected 
that these demand related stresses would be clearly 
reflected in the filtering process. In particular one would 
expect that requirements not fitting into a certain meld of 
acceptability would have less chance of passing unhindered 
through the filter during periods of heavy demand rather 
than light demand. Ihus, it becomes clear why the initial 
definition of the requirement process is very important. It 
helps to insure that a user generated requirement is 
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described in teras the requirement filtering process can 
unde rstand. 

e. Time 

This is one of the most important and compli- 
cated of all priority parameters. The following paragraphs 
describe some of the time related concepts which relate to 
the filtering process of the requirements system. 

Many organizations in a given unit have similar 
intelligence needs. As a result, often identical (or nearly 
so) intelligence requirements are placed into the intelli- 
gence system. To limit the waste associated with this type 
cf problem the intelligence system periodically prepares 
reports cf common interest. Numerous (primarily routine) 
intelligence requirements can be satisfied through the 
publication of timely periodic intelligence reports. The 
publication of such reports should thus have some effect on 
the requirements filtering process. Specifically, the 
timing of these reports will be of some importance. For 
instance, requirements submitted into the system which one 
can expect will be reasonably well satisfied (from a timeli- 
ness and quality of information point of view) with a soon 
to be published periodic report should probably be rejected 
with the caveat that the information will soon be forth- 
coming. Of course, measures must be taken to insure that 
the requested information does eventually get to the user 
whose requirement was initially rejected. 

An additional aspect for consideration with 
respect to the publication of such reports is that of 
resource alloction. The publication of periodic reports 
places a drain on the capability of the intelligence system 
similar to the type cf drain placed on it by excessive quan- 
tities cf users. Thus, there is a cost associated with the 
production cf such reports. This cost should be defined and 
reflected in the filtering process. 
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One can look at the publication of periodic 
reports as an action which decreases the requirement load on 
the intelligence system (by making the filtering process 
more stringent) while the resources allocated in preparation 
of the intelligence reports can be looked upon as an action 
which increases the stress on the intelligence system (by 
reducing the resources available for the satisfaction of 
requirements). A good balance between value and cost m cst 
exist if periodic reports are to be useful to the intelli- 
gence system. 

On occasion, requirements can conflict with 
ongoing collection operations. This is similar to the 

consideration addressed above. During certain types of 

intelligence operations one can expect that nearly all (or 
some significant portion) of available intelligence 
resources might be employed. At these times it is possible 
that many valid intelligence requirements which might 
disrupt an ongoing intelligence operation may not be satis- 
fied. The point to be made is that the failure to address 
the valid requirement is not necessarily due to the overall 
lack cf resources available but rather the fact that the 
specific requirement, from a temporal point of view, has 
come into conflict with an ongoing (resource draining) 
intelligence operation. At any other point in time it is 
conceivable that the same requirement may have been satis- 
fied. Therefore, the timing cf intelligence operations (in 
particular the scheduling of such operations) is possibly an 
important input parameter to the requirements filtering 
process. This difficulty can be limited by interfacing with 
the appropriate users to determine if delays in satisfaction 
of the requirement might be somewhat acceptable. 

There exist time delays associated with the 
production of certain forms of intelligence. These time 
delays, when contrasted with the time constraints cf a 
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particular intelligence requirement itself, may net allow 
for the satisfaction of the requirement. Such delays may 
come in the form of a lead-time delay (applicable in certain 
scheduled types cf operations or in operations which require 
a certain amount of warm-up time prior to producing intelli- 
gence), and lag-time delays (applicable in the situation in 
which the requirement time restraint is shorter than the 
resource time restraint - thus information produced to 
satisfy the given requirement will be late (and probably 
less than optimal). 

The filtering process must therefore be able to 
compare two classes cf time restraints - those associated 
with the user's actual intelligence requirement and those 
associated with the intelligence system. Figure 2.3 
outlines this time analysis process. 





Figure 2.3 Time analysis. 
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figure 2.4 outlines the flew of a requirement 
entire filtering process. 
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3. C € t ail ed Reg uireme n ts A paly si 5 

After passing through the filtering process a 
reguirement is considered to he valid - something which the 
intelligence system must react to (and hopefully satisfy) . 
However/ the functional structure of the intelligence system 
(requirements/ analysis, collection) is fairly strict. 
Thus, the reguirement must he further translated into func- 
tional terms which the system can act upon. The first step 
in this process is determining the dimensionality of the 
reguirement. The dimensionality of a given intelligence 
requirement refers tc whether or not that requirement can be 
satisfied using analytical intelligence resources, collec- 
tion intelligence resources, or a combination of the two 
types of resources. Thus, a requirement can be thought of 
as being single dimensioned (either an analytical or collec- 
tion reguirement) or multi-dimensioned (an analytical and 
collection requirement). Figure 2.5 (Detailed Requirements 
Analysis) illustrates the dimensioning possibilities related 
to any given intelligence requirement. 

Determination of the dimensionality of a given 
requirement may be a fairly complicated process. This is 
particularly true with respect to multi-dimensioned require- 
ments. Such issues as resource availability and time become 
important factors which can create variability in the dimen- 
sionality of a requirement. For instance, given a rather 
vague reguirement such as: 

- Khere will the enemy 2nd echelon be deployed? 

Cne can envision the difficulty of determining which aspects 
of the requirement are analytical in nature and which are 
more collection oriented in nature. 

It should be noted that once the dimensionality of a 
given reguirement has been determined, it is not necessarily 
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Figure 2.5 Detailed Beguirements Analysis. 

static. Specifically, the changing availability of analyt- 
ical and collection resources affects the dimensionality of 
any giveE requirement. This fact suggests that some sort of 
interface should exist between the operational structures of 
the intelligence system with respect to valid intelligence 
requirements. 

Cnee the dimensionality of a given intelligence 
requirement has been determined, it will be passed tc the 
appropriate systems (analytical and/or collection). Each 
system will then continue to redefine the requirement into 
terms which relate tc their own functions. 

At this point in the process the requirements system 
has completed its function of receiving the requirement. 
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deter mining whether cr not that requirement will he acted 
upon ty the intelligence system, and forwarding a more func- 
tionally oriented requirement to either the analytical 
system, collection system, cr toth. 

E. ANALYTICAL SYSTEM 

1 . Object ive and Struc t ure of the A naly t ica l Sy st em 

The objective of a n analytical system is to piece 
together data from a variety of sources (to include judge- 
mental) to provide the user with intelligence information of 
value. Given the intelligence system structure depicted in 
Figure 2.1 and the previous discussion concerning the intel- 
ligence requirements system, an analytical system might 
appear as that shown in Figure 2.6. Several features of 
this structure are noteworthy. 




Figure 2.6 Analytical System. 
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• Ti me Considera tion s of the Analy tical Syst em 

a. Analysis Under Conditions of Partial Information 

Time restraints often require that analysis be 
performed with only a portion of the required information 
available. In this situation of partial information subjec- 
tive judgements tend to bridge the gap between known infor- 
mation concerning the current situation and previously 
determined battlefield relationships. Analysis of this 
nature is risky in the sense that it is based upon a less 
than adeguate informational foundation. 

b. Analysis fiith Conflicting Information 

Analysis often occurs under conditions of 
conflicting information. Information pertaining to an 
intelligence requirement will sometimes be of a contradic- 
tory nature. In this situation the analysis activity must 
be able to evaluate which information is best suited for 
inclusion in the analytical process. This evaluation can be 
complicated and time consuming in that questionable informa- 
tion cf potential importance may be of such a complicated 
form that it must first be re-evaluated by the collecting 
activity. Subsequent time-lag complications often hinder 
the information evaluation process even further. The net 
result of these complications is that the decision as to 
which set of information is more accurate becomes judge- 
mental and often less than objective in nature. 

c. Time and Spatial Projection of Analyses 

Intelligence analysis must be predictive in 
nature. Thus, the analysis activity must be able to (based 
on past information fcr the most part) project their anal- 
yses into the future to answer such questions as: 

- When will the enemy be prepared to attack? 



32 



(Front 



- When will the 2nd echelon arrive at the FLOT 
Line cf Troops)? 

Additionally, the analysis activity must be able to project 
from a spatial point cf view. For instance, analysis must 
address guestions of the form: 

- Where will the enemy be located in 6 hours? 

Some of these predictive evaluations may be 
suited to mathematical models. Specifically, movement 
models and enemy arrival rate models may have a certain 
level cf applicability. However, the information upon which 
models must depend may or may not be at a level of accuracy 
or precision which is required for satisfactory model 
performance. 

For the resaons mentioned in the previous 
discussion it should be clear that modeling an analysis 
system would be a difficult task due to its subjective func- 
tional nature. Fortunately, this study is only concerned 
with the relationship between the collection system (the 
primary subject of this study) and the analytical system. 
Specifically, an analytical system tasks a collection system 
to help satisfy intelligence requirements. 
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III. A COLLECT I CN SYSTEM OVERVIEW 

A. CEJECTIVE OF A CCILECTICN SYSTEM 

The objective of a collection system is to satisfy, in 
the context of the battlefield situation, informational 
shortfalls resulting from intelligence requirements being 
placed upon the intelligence system. A collection system 
accomplishes its objectives through the employment of a wide 
variety of sensors (both human and technical) which have the 
capability of detecting different forms of enemy activity. 
The employment of these sensors, however, is not necessarily 
direct. For the remainder of this study intelligence 
collection sensors will be referred to as collection plat- 
forms. Collection platforms can be highly specialized 
(discussed in more detail later) . The operation of such 
platforms, accordingly, is often complicated and requires 
substantial personnel and support resources. These 

resources, to include their related collection platform(s), 
will be referred to as a collection subsystem. A collection 
system is composed of one or more collection subsystems 
(normally mere). Thus, a collection system acquires needed 
intelligence information through the management of one or 
more collection subsystems. 

E. STBOCTOEE OF A CCILECTICN SYSTEM 

1. Collec tion Plat for ms 

Collection platforms are sensors, both human and 
technical, which possess seme capability of detecting 
certain forms of enemy activity or presence. Operationally 
deployed platforms are numerous in quantity and vary greatly 
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in their functional medium and operational capabilities. It 
is easy to distinguish and separately classify human plat- 
forms from technical platforms. Different types of tech- 
nical platforms are more difficult to classify. Normally 
they are categorized into groups according to the manner in 
which intelligence information is collected. For instance, 
those which collect signal related intelligence information 
are grouped into a functional category referred to as SIGINT 
{standing for signal intelligence) platforms. Similarly, 
those technical platforms which employ images in the collec- 
tion process are grouped into a functional category referred 
to as IflINT (standing for imagery intelligence) platforms. 
For obvious reasons, human intelligence sensors are referred 
to functionally as HOMINT platforms. 

As previously mentioned, collection platforms are 
useful because they possess a valuable operational capa- 
bility. This capability can be defined as a function of the 
following parameters: 

a. Functional Medium (M c) 

For humar platforms the medium is obvious. 
Technical platforms tend to operate (collect information) at 
some location (or within some range) of the electromagnetic 
spectrum. For instance, ccmmunicati ons intercept platforms 
normally collect information over some range of frequencies 
(and transmission modes) - HF, microwave, etc. Similarly, 
photographic platforms collect over some range of light 
frequencies - IR, visual, etc. 

b. Functional Capability (C^) 

Given the medium in which a platform operates it 
must also possess scire limits to its sensing capabilities. 
Those limits might be resolution levels, sensitivity levels, 
maxi mum/minimu m range capabilities, etc. 
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c. Physical Medium 
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The operational capability (O.C.) of a collec- 
tion platform can be represented by the following 
relationship: 

cc = /< C*, M . C T ) (eqn 3.1) 

J 1 - P p 



2. Col lec t ion Subsystems 

A collection subsystem consists of those resources, 
both human and technical, which directly control the opera- 
tional employment of a collection platform. One or more 
collection platforms may be under the control of a collec- 
tion subsystem at any given time during an operation. 
Collection platforms, when under the control of a collection 
subsytem, are considered part of the collection subsystem. 

Collection subsystems normally control platforms 
which are functionally related to one another. For 
instance, a signal intelligence collection subsystem would 
normally control collection platforms which are capable of 
detecting and perhaps analyzing enemy communica ticns and 
non-ccmmunications emitters. Likewise, an imagery intelli- 
gence collection subsystem would normally consist of all 
collection platforms which, in the process of collecting 
information on the enemy, produce images for analysis. On 
occasion, collection subsystems are organized along less 
functional lines. For instance, there exist both Army and 
Air Force collection platforms which produce radar images of 
potential battlefields. Although the platforms are func- 
tionally similar they are not normally found under the 
control of a single collection subsystem. Each service 
tends tc control its own platforms. Thus, in this 
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situation, functionally similar collection platforms are 
controlled by separate service related collection 
subsy stems. 

It seems reasonable to suggest that the operational 
capability of a given collection subsystem might be 
expressed as the sum of the operational capabilities of its 
collection platforms. This relationship might be valid if 
it could be shown that the parameters of each platform were 
independent of one another. Unfortunately, this is net true 
in all cases. 

a. Functional Medium 

In the event the collection platforms operate in 
entirely different portions of the electromagnetic spectrum 
then one could reasonable argue for independence with 
respect to this parameter and a simple subsystem parameter 
could be formulated. Otherwise, some relationship between 
platforms would exist and the formulation of a subsystem 
parameter would be more difficult. 

rf 

b. Functional* Capability 

In the event that the functional medium of the 
platforms of concern were determined to be independent then 
it is likely that their functional capability parameters 
would also be independent of one another. If their respec- 
tive M^s were dependent, however, then there would be a 
possibility that they would also be dependent with respect 
to the capability parameter. 

c. Physical Medium 

In the event that two or more collection plat- 
forms reguired an identical portion of a physical medium in 
which to operate then a dependent relationship with respect 
to this parameter would exist. At first glance, the 
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Figure 3.1 Dependency Analysis. 

determine. Thus, the suggestion to repc esent the 
operational capability of a given collection subsystem as a 
simple sum of the operational capabilities of its collection 
platforms is not justified except in cases where no depen- 
dencies exist. 

Further investigations in determining these 
sorts of relationships would certainly be appropriate. For 
the purposes of this project, it will be assumed that a 
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composite relationship representing the 
parameters of a group of collection platfor 
formulated. From this composite relationship a 
tion of the operational capability of a given 
subsystem could be formulated. 

Recall that collection subsystems of 
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subsystem. The operational capability of a given 
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form capabilities (discussed above) and any ef 
inefficiency multipliers associated with the mana 
collection subsystem. 
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Figure 3.2 Collection Systems Structures. 

important concept. The implication being that as the course 
of the tattle changes, the structure (and hence capability) 
of the intelligence collection system will also change. 

The next portion of the study will address the functions 
of the various components of the collection system 
structure. 
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FUNCTIONS OF A CCILECTICN SYSTEM 
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2. Collection Subsystems 

Collection subsystems control the operation of one 
or more collection platforms. As a controlling source they 
must provide control input which is understandable to each 
platform within the subsystem. From each platform the 
collection subsystem receives intelligence data. 

Collection subsystems are also controlled by collec- 
tion systems. As a controlled system it must receive 
control inputs from its controlling source and provide 
intelligence data (perhaps translated) to the controlling 
source. The control inputs from the collection system to 
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Figure 3.3 Collection Platform Functions. 

the subsystem will not be identical to those from the 
subsystem to the platform. They (subsystem to platform 
inputs) will for the most part, however, reflect the inten- 
tions of the system to subsystem inputs. Likewise, the 
intelligence data received from the platform may not be 
identical to that forwarded from the collection subsystem to 
the collection system. 

Technical and specialized platforms require precise 
control inputs and return precise data - neither of which is 
normally comprehensible to the untrained user. Thus the 
requirement for the subsystem to serve as a translator. As 
the number of collection platforms increase in a given 
collection subsystem cne can easily see how the functional 
complexity cf the subsystem increases. This is particularly 
true in the case of widely varying types of collection plat- 
forms. Figure 3.4 depicts the functions of a collection 
subsystem. 
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Figure 3.4 Collection Subsystem Functions. 

3. Col lect ion Systems 

Collection systems control the operations of one or 
more collection subsystems. To accomplish this task the 
collection system forwards controlling inputs to appropriate 
subsystems and receives intelligence data from them (or on 
occasion directly frcm a collection platform) . The collec- 
tion system is also controlled (as previously mentioned) by 
ether elements within the intelligence system (analytical 
and collection systems) . A collection system is function- 
ally similar to the general collection subsystem shown in 
Figure 3.4. In this case, however, the controlling sources 
are elements of the intelligence system and the platforms 
are collection subsystems. Figure 3.5 depicts the 
functional nature of a collection system. 
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Figure 3.5 Collection System Functions. 

E. GENEBAL CONSIDERATIONS CF 1 COLLECTION SYSTEM 

Given the intelligence system structure outlined in 
Chapter Two and the discussion in this chapter it is cow 
possible tc illustrate, in more precise detail, how a 
collection system fits into that structure. The system at 
Figure 3.6 is a multilevel depiction of the intelligence 
system with the strata being the collection platforms, 
subsystems, collection system, and finally the intelligence 
system. 



1 • Multip le C ollectio n Platforms and S ubsys t ems 

Complexity increases as more collection platforms 
(and subsystems) are added to the intelligence collection 
system. More resources are required tc manage the 
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Figure 3.6 Collection System Overview. 
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2 • Cy namic Struc tur e 

Changing battlefield conditions often dictate 
changes in military organizational structures. As alluded 
to in previous discussion, collection systems experience 
such battlefield structural changes. These changes are 
often more abrupt (occur without warning) than these found 
in more typical military units. This is the result of the 
multiservice/multicommand make-up of collection platforms 
and subsystems. This dynamic structure adds complexity to 
both the management of the collection effort and the 
resulting data flow. 



3. Time and Spati a 1 Proj ect io n of Int ell i gence 

Coll ection 

The intelligence collection system, for the most 
part, responds to the needs of the the Requirement and 
Analytical Systems of the Generalized Intelligence System. 
These needs invariably are more concerned about the future 
nature of the enemy on the battlefield rather than their 
current status. As a result, the collection effort must 

also be focused on the future. This orientation adds 

complexity in planning and implementing intelligence collec- 
tion operations. lead/lag time considerations for both 
platform performance and the many levels of planning 
required is a difficult problem in itself. Much effort is 
currently aimed at solving scheduling problems arising from 
lead/lag time considerations. Added to these time difficul- 
ties is the spatially dynamic nature of the battlefield. 
The location of the enemy forces of concern at unknown 
future times is difficult to determine. Thus the future 
orientation of the intelligence system tends to create plan- 
ning and implementation difficulties for the collection 
system. 
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Mul tip le Users w ith Diffe rent and Changing. Lev els of 
A cc ess 

Numerous users are allowed access to the resources 
of a collection system. The mere variety associated with 
such numlers imples that a collections systems’s capabili- 
ties (with respect tc both the collection effort and trans- 
mission of information) must be broad. Increased guantities 
of users leads to obvious difficulties in managing any 
complex system. Users of a collection system are, with the 
aid of a priority system, allowed varying degrees of access. 
A high priority unit would normally be allowed greater 
access than a lew priority unit. The priority of access 
often changes during the course of an operation as units are 
shifted about the battlefield. The collection system should 
he able to cope with such changes. 

These and ether considerations suggest that a 
description of the structure and functions of a collection 
system might be somewhat complicated. The collection system 
is not the master of its <^n destiny. The number of users 
(and their level of access) as well as the number of 
resources needed to satisfy those users both vary as a 
function of current battlefield conditions. 



IV. COLLECTION REQUIREME NTS 



The control parameters of collection systems, subsys- 
tems, and platforms are intelligence collection requirements 
cr translated portions of intelligence collection require- 
ments. To understand the nature of the collection system 
one mcst understand collection requirements. This chapter 
will address the traditional perspective of collection 
requirements, describe their flow through a collection 
system, and suggest a more analytical view of a collection 
requirement . 



A. SOURCES AND TYPES OF COLLECTION REQUIREMENTS 

A collection requirement is leveed against a collection 
system as a result of a informational need identified by the 
user. All users in this systems structure can be thought of 
as members of one of the three sub-elements of the 
Generalized Intelligence System. Therefore, collection 
requirements can enter a collection system from one of the 
following three sources: 

1 . Requirements S ystem 

Collection requirements originating from a require- 
ments system are those which have been initially identified 
as requiring some degree of intelligence collection effort 
prior to being satisfied. An example of such a requirement 
might be: 

- Determine if enemy tanks are located at coordinates 
ABxxxxxx . 

An intelligence database could address the question of 
whether cr not tanks were located at those coordinates at 
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some point in time in the past. Collection at that location 
in near real time, however, must he accomplished in order to 
answer the requirement as stated. 

2 . Ana lyt ical System 

Collection requirements can originate from an anal- 
ysis system in two primary fashions. The initial evaluation 
of the intelligence requirement by the requirements system 
as primarily analytical in nature (its dimensionality) could 
have been, to some degree or another, incorrect. An anal- 
ysis system would, in this situation, not have the assets 
available to satisfy such an ill-assigned requirement and 
would be forced to pass the requirement onto the collection 
system for satis fact icn. An example of such a requirement 

might be: 

- Notify the 3rd Erigade if there is an increase in 
moving target activity in their sector. 

This requirement is clearly oriented toward a surveillance 
(and hence collection) activity. An analysis system would 
not normally have under its operational control such a 
surveillance capability and thus would be unable to effec- 
tively respond to the requirement. 

The initial intelligence requirement may have been 
primarily analytical in nature but may have required addi- 
tional collected information to enhance or upgrade the 
quality cf analysis. An example of this type of requirement 
is: 

- Eetermine the capability of the enemy force located at 
coordinates ABxxxxxx. 

This is clearly an analytical requirement yet accurate 
collection (to determine the type and size of the enemy 
force) must be accomplished in order to more accurately 
perform the analysis. 
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Ihe differences in both of these cases described 
above are really a matter of degree. The first case alludes 
to the possibility that a mistake in the assignment of 
reguirements may have been made. The second case concerns 
those times when more information is needed to satisfy a 
given requirement. 

3. ' Col lec tion Sy stem 

A collection system will, in order to maintain 
itself, generate collection reguirements. These are the 
overhead costs of the collection subsystems. An example of 
such a requirement is: 

Determine radio frequencies the enemy is using to 

control its nuclear capable artillery. 

In this case the radic frequencies are, in themselves, of 
little intelligence value to the user. However, they are 
vital to the SIGINT collection subsystem which is tasked 
with providing ether forms of intelligence concerning such 
enemy forces. 

In erder to speed up the requirements and collection 
processes special types of collection reguirements have been 
developed. The most common of these are listed below: 

a. Standing Eeguir ements 

Standing requirements are those which a collec- 
tion system is nearly always attempting to satisfy. 
Normally, standing requirements are applied to informational 
shortfalls cf obvious importance. 

- Enemy nuclear activity. 

- Significant enemy movement on the battlefield. 

- The location of enemy command posts. 
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The Army has traditionally referred to these sorts of 
requirements as EEI/CIR standing for Essential Elements of 
Information and Other Intelligence Requirements. 

1. Fast-Track Requirements 



Fast-Track Requirements. Fast-track requirements 
are those which, because of their time sensitive nature, are 
allowed to ty-pass normal collection procedures. 

- Verification of the location of an artillery target. 



- Determination of target status for nuclear target 
planning. 

- Any hot requirement of importance. 



c. Dedicated Resources 
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Special variations of collection requirements initiated in a 
requirements and analytical system are shown as inputs into 
special requirements. This is not meant to indicate that 
special requirements not related to those systems cannot 
exist independently. A dedicated resource requirement is an 
example of such an independent special requirement. 
Additionally, a collection system requirement can be thought 
of as totally enclosed within the collection system. Its 
primary function is to support collection platform and 
system operations although intelligence information gener- 
ated from its application would, of course, not be ignored. 




Figure 4.1 Requirements Flow. 

The following discussion addresses the nature of the 
collection requirement as it relates to collection subsys- 
tems and their related collection platforms. For illustra- 
tive purposes the first portion of this discussion will 
address the relationship of a single collection requirement 
as it enters a single collection subsystem with its related 
platform (s). An example of such a collection subsystem 
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might he the Aerial Seconna issance Subsystem containing such 
platforms as SLR and various other photographic sensors. 

Traditionally, a collection requirement is forwarded, 
for the most part, to a collection subsystem in its 
entirety. The operators of the particular subsystem and 
platforms would then determine how the collection platforms 
under their management might he able to satisfy the given 
requirement. Occasionally, a collection requirement might 
he well suited to satisfaction by a particular subsystem and 
platform. On other occasions there may be little 
applicability. 

This approach toward the management of intelligence 
requirements came about through an evolutionary process. 
Factors which shaped this prccess (and which will not be 
thoroughly addressed in this paper) include: 

- The technical orientation of specific collection plat- 
forms. 



- Security procedures f compartmentation) related to 
specific collection platforms and subsystems. 

- M ulti- servi c e use of collection platforms. 

- The limited data processing capabilities of battle- 
field users. 



- Limited communications capabilities. 
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isadvantages associated with this 
h toward collection management, 
ecific collection subsystem are 
e collection requirement and are 
their subsystem to satisfy that 
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55 



Disadvantages tc this system become apparent when 
looking at a group of collection subsystems operating under 
a single system. This is the more realistic situation. A 
glympse cf the potential complexity of such a system can be 
seen at Figure 4.2. Some of the specific disadvantages 
include the possibility for the occurrance of uncontrolled 
redundancy cf effort and the possibility that one or more 
collection subsystems can become saturated with collection 
requirements while ethers operate at less than optimal 
levels of efficiency. This type of control problem can 
become important when one considers the fact that intelli- 
gence information is generally of a time sensitive nature 
and hence delays in satisfaction of a requirement will 
degrade the value -of the information required by the user. 

In an attempt to provide some sort of administrative 
contrcl and traceability of the great quantities of collec- 
tion requirements in the collection system a collation 
process has evolved. The exact structure and manner in 
which this process works is ad hoc and varies greatly from 
unit to unit. Some processes are more efficient than 
ethers. All of these processes do have some features in 
common. First, they attempt to filter out unsuitable 
requirements. Second, they attempt to keep track cf which 
users have submitted which requirements. Finally, they 
attempt to get appropriate requirements to those collection 
subsystems which may be able to satisfy them. 

Once collection subsystems have responded to a collec- 
tion requirement (through platform collection or perhaps a 
negative response) then a sort of reverse collation process 
- dubbed Collection Fusion - takes place. Similar tc the 
initial collation process described above, one goal of this 
process is to match information/intelligence data to the 
users that requested it. Great efforts and achievement have 
teen made in recent years in the area of collection and 
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Collection System Boundary 



f 




Figure 4.2 Composite Collection System. 

intelligence fusion. For this reason, the topic of collec- 
tion fusion will not te addressed in detail in the remainder 
of the study. 

Thus, most collection systems deployed by major units 
today are similar in structure to that shown in Figure 4.3. 
Prior tc investigating methods which could improve the 
collection management process outlined in this chapter it is 
first necessary to examine, in more analytical detail, the 
nature of a collection requirement. 
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Figure 4.3 Traditional Collection Management Approach. 

C. DECOMPOSITION OF A COLLECTION REQOIHEM ENT 

Collection requirements entering a collection system 
are, in general, net in a form which collection subsystems 
and platforms can immediately use. Normally the requirement 
must first be re-expressed into more familiar terms which 
have a mere direct relationship to those tasks which subsys- 
tems and platforms perform. This re-expression process 
tends to narrow the scope of the original collection 
requirement into mere manageable portions. Collection 
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subsystems subjectively accomplish this re-expression in 
many collection systems found in use today. The 

re-expressicn of a collection requirement into a set of 
smaller# more manageable subreguirement s will be referred to 
in this study as the decomposition of a collection 
requirement . 

Upon receipt of a collection requirement a given collec- 
tion subsystem will attempt to interpret the meaning of that 
requirement in terms of its own subsystem and related 
collection platforms. For example, given an incoming 
collection requirement of: 

- Determine if the enemy forces located at X are 
preparing to attack. 

An aerial reconnaissance collection subsystem might generate 
the fcllcwirg subreguiremen ts: 

- Take an aerial photograph of location X to determine 
if the enemy located there is in an attack posture.* 

- Provide moving target radar coverage of area X to 
determine if the enemy is moving toward friendly lines. 

Given the same collection requirement a signal intelligence 
collection subsystem might generate the following subre- 
quire lent : 

- Intercept the radio communications of enemy units 
located at X to determine if they are preparing to 
a ttack. 

It is possible (and in practice often occurs) that a collec- 
tion subsystem might not be suited to such a collection 
operation and would not be able to generate any feasible 
collection subrequirements. 

Note that in the examples provided above that the gener- 
ated subrequirements have been re-expressed with respect to 
the capabilities of the collection subsystem. Also, 
although each subreguirement appears to be directed toward a 
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single collection platform, this may not be the case. For 
instance, it is possible that several subreguirements 
derived from a single collection requirement may be directed 
toward the same collection platform. Finally, each of the 
subreguirements in the example are basically qualitative in 
nature. They capture the nature and intent of the original 
requirement without dealing with any of the more specific 
parameters of the requirement. 

Taking this decomposition process one step further, 
consider first the subrequirement of the aerial reconnais- 
sance collection subsystem (labelled with an astirisk 
above). An aerial photographic collection platform may 
decompose that s ub reguireme nt in the following manner: 

- Provide black and white, low panoramic and vertical, 
photographs of location X. 

- Provide black and white, low panoramic and vertical, 
photographs of major roads leading from location X to 
the nearest friendly forces. 

Although these subreguirements are certainly very detailed 
(when compared to these of the collection subsystem) , they 
still are oriented toward the satisfaction of the nature and 
intent of the original collection requirement. 

The subreguirements addressed in the preceeding para- 
graphs will be labelled as quality subreguirements. Any 
given collection requirement will also have associated with 
it another set of parameters which are more technical in 
nature. The primary example of such a technical parameter 
is the time restraint associated with a given 
subr eguirement . 

Time restraints were mentioned briefly in Chapter One as 
they pertained to general intelligence requirements. Many 
of the same concepts apply with respect to the decomposition 
of collection requirements except in a much more detailed 
fashion. A collection requirement enters the collection 
system with at least two time restraints associated with it. 
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- The tine by which the user must have the desired 
in f or 2 a ti cn. This restraint tells the collection system 
when the collected intelligence must be in the user's 
hands. Commonly used terms describing this restraint 
are "best possible" or "as soon as possible" (both of 
which provide some degree of system flexibility) and 
"net later than/not earlier than" formats (which tend tc 
be mere restrictive). 



- The desired time cf collection. This restraint lets 
the collection system know that the value or quality of 
the collected intelligence is at least partially depen- 
dent upon the time in which it is collected. Formats in 
common use tend to specify a point in time, identify a 
time window during which collection should be accom- 
plished, or require that collection be accomplished 
continuously f cr seme length of time (in this situation 
the collection function becomes more of a surveillance 
£ unction) . 



These technical restraints, similar to the quality 
subreguirements, must be expressed with respect to the 
specific collection subsystems and eventually their collec- 
tion platforms. There exist other technical restraints 
associated with any given collection subrequirement . These 
will not be specifically addressed in this thesis but are 
considered in all algorithm development. 

A single collection subrequirement if portrayed graphi- 
cally (and decomposed to the collection subsystem level) 
would contain information describing where it originated 
(some sort of tag associating it with a user or set of 
users), the quality or nature of the subrequirement, the 
collection subsystem it is associated with, and all appro- 
priate technical restraints. The structure of a subreguire- 
ment might look like that shown at Figure 4.4. As 
previously mentioned, the decomposition of collection 
requirements is traditionally accomplished by the collection 
subsystem relying heavily upon expert judgement and prior 
practices/standard procedures. Therefore the subrequirement 
structure depicted above should be viewed at this point in 
the thesis as a tool to enhance understanding of a collec- 
tion subreguirement. 





Qua 1 f ty 


Technl ca 1 


Associated 


User X 


Subrequirement 


Restra 1 nt 


Subsystem 



Figure 4.4 Sub requirement Structure. 

If one were to group all of a single collection require- 
ment's subr eguiremen ts into one construct it might appear as 
that shown in Figure 4.5. The collection system , in this 
case, consists of three collection subsystems - 1, 2, 3. 
The collection requirement originated from unit number 2 and 
was decomposed by the collection subsystems into three 
subreguirement s. 
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Figure 4.5 Collection Requirement Vector. 

It could be demonstrated, using an example of collection 
platform requirement decomposition, how this process can 
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continue tc the highest levels of resolution. However, this 
study is focused on the relationship between the collection 
system and subsystem and will not, therefore, develop the 
decomposition methodclogy any further than that already 
presente d . 



D. TEE INTELLIGENCE COLLECTION MANAGEMENT PROBLEM 
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Figure 4.6 Eestructured Collection System. 

Cnly those requirements (or sutreguirement s) best suited for 
satisfaction by a subsystem would be forwarded to that 
subsystem for collection action. Unwanted duplication of 
effort could be more easily limited with this structure. A 
more balanced use of all collection subsystems could be 
controlled from the collection system level. These effi- 
ciencies are important but of a fairly administrative 
nature. 

The real advantage of this structure is that it allows 
for the application of optimization methods to the 
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collection resource allocation problem. At this point in 
the collection management process we are now aware of the 
demands (in the form cf requirements) placed upon the system 
and cf our resource constraints (available collection 
assets) . Kith some added input from the collection subsys- 
tems concerning their operational capabilities we will be in 
a position to apply powerful optimization procedures tc the 
allocation problem. These procedures will be addressed in 
Chapter Five. 
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7. THE INTELLIGENCE COLLECTION MANAGEMENT MODEL 
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A. THE EASIC COLLECTION SYSTEM MODEL 



The basic 



collection system model is described below: 



MAXIMIZE: 
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(egn 5.1) 
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1 



1,...,n (i is the index for collection require- 
ments. There are a total of n collection require- 
ments considered in the requirement set of the 
la sic model) 



1,...,m {j is the index for collection subsys- 
tems. There are a total of m collection subsys- 
tems considered in the basic model) 



d ii 



The decision to allocate collection resource j to 
collection requirement i (0 = no, 1 = yes) . 






The amount cf collection resource j allocated 
toward the satisfaction of collection requirement 
i if d^j = 1 (units are subsystem collection 
hours - hrs) . 






Total amount of subsystem j collection resources 
available for use is satisfying the set of collec- 
tion requirements n . 



v 

i 



Relative importance associated with requirement i 
(priority). Requirement priority will not be 
considered in the basic model and therefore 
v^ = 1 in the basic model. Requirement priority 
will be addressed in Section 3.2 of this Chapter 



where values cf v ^ will be allowed to vary. 



Expected fraction cf requirement i satisfied by 
those collection subsystems (j = 1,...,m) tasked 
to satisfy that requirement. 
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tinary: 



d . .= 

i] 



Lee isi o n Variables 

lie decision variable used in the basic model is 

0 if subsystem j does not allocate collection 
resources to satisfy requirement i. 

1 if subsystem j does allocate collection 
resources to satisfy requirement i. 



This implies that the basic model will only determine 
whether cr not it should allocate a predetermined and fixed 
amount of collection resource from subsystem j toward the 
satisfaction of requirement i. The importance of this 
assumption and decision rule are great. It does net allow 
the model to vary the amount of collection resource it allo- 
cates toward the satisfaction of a requirement. It either 
allocates a fixed and predetermined amount of resource (a • ; ) 
cr none at all. Collection subsystems, in other words, can 
only attempt to satisfy a collection requirement by allo- 
cating resources i'n one specific manner. At first glance, 

the use of this ftype of decision variable seems to be a 

< 

harsh and unrealistic constraint on the model. Such a 
perception is inaccurate. 

The great majority of tactical intelligence require- 
ments fall into one of several classes of requirements. 
Targeting requirements form such a class. In order to 
satisfy a targeting requirement the collection system must 
basically provide the user (requestor) with information 
concerning the location, dispersion, nature (its type of 
activity) , and level of protection (armored or not) of a 
potential target. Collection subsystems which posess the 
capability of at least partially satisfying targeting 
requirements have developed SOPs (standard operating 
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collection requirements. Thus, the basic model developed in 
this study should be considered applicable to such classes 
c£ requirements. 

There exist collection requirements to which the 
decisioc variable d . . is not well suited. Certain require- 
ments, for instance, can be satisfied by collection subsys- 
tems at varying levels of satisfaction rather than at a 
single discrete level of satisfaction as suggested in the 
basic model. An example of such a subsystem might be that 
of the signal intelligence collection subsystem. Clearly, 
the level of satisfaction of certain requirements would 
increase (to a point of diminishing marginal returns) as 
more hours of signal intercept time are applied to the 
satisfaction of the requirement. He would also suspect that 
this level of effectiveness function might be continuous and 
monotone increasing (i.e. 1.5 hours of intercept time cannot 
be less effective that 1.0 hours of intercept time). In 
such situations a more suitable decision variable x — should 
be used. 

x. . = The amount of collection resource from subsystem j 

allocated toward the satisfaction of requirement 
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The application of this type of decision variable to the 
basic model will be addressed in Section 3.4 of this 
chapter . 

2 . Bes our ce Const rai nt s 

In the basic model it will be assumed that each 
collection subsystem j has at its disposal a fixed amount of 
collection resources. Let b • be defined in the following 
manner: 

b^ = The total amount of subsystem j collection 
resources available for allocation toward the 
satisfaction of collection requirements. 

Thus, bj is a constant in the basic model. The units of 
fc are subsystem collection hours. Thus, the overall 
resource constraints of this model can be represented in the 
following manner: 



2 



= l 



d . . a . . 
i] il 



^ V j ( j = 1, . . . ,m) 



(eqn 5.2) 



Let a . . he defined in the following manner: 

i] 

a. . = The amount of collection resource j allocated 

il 

toward the satisfaction of collection requirement 
i if d^j = 1 (in subsystem collection hours) . 

The relationship between collection subsystems and 
collection requirements is critical to this model. 
Specifically, collection subsystems, in the allocation of 
their specific collection resources, contribute to the 
satisfaction of intelligence collection requirements. There 
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§ of intelligence requirements 

collected against while on target (eqn 5.3) 
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In this sense a . .. can be interpreted as equaling the cumber 
of aerial reconnaissance subsystem collection hours consumed 
in attempting to contribute to the satisfaction cf collec- 
tion requirement i. 

Tactical signal intelligence subsystems typically 
have at their disposal many operators (analysts) who extra- 
polate from intercepts and other signal data information 
relevant tc the satisfaction of collection requirements. 
Each operator is able to work a fixed amount of hours 
performing his function. If two subsystem operators each 
must spend four hours performing their function in 
attempting to contribute to the satisfaction of a given 
collection requirement then eight subsystem collection hours 
have been allocated to that requirement. The following 
relationship holds with respect to this collection 
subsystem: 

(amount of subsystem 

hours per position) x (number of positions) 

a . . = 

^ (number of intelligence requirements 

collected against) (eqn 5.4) 
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interpretation cf a ■ • is similar to that of the 
eeding example - the number of signal intelligence 
ystem collection hours consumed in attempting to 
ribute to the satisfaction of collection requirement i. 

It is a simple matter to make allocation calcula- 
s once collection has already occurred. If the collec- 
model is to be useful, however, it must be able to aid 
decision maker prior to the actual allocation of collec- 
rescurces. To do so this model therefore requires that 
values be known or estimated prior to the resource allo- 
on decision. How can this a priori estimation of a^ be 
mplished? 
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at the same time bounded by norms and SOPs. For example, an 
aerial reconnaissance subsystem operator may be authorized 
to make a., estimates of integer subsystem collection hours 
less than three. In other words, he is not authorized to 
provide ron-integer estimates cr estimates of allocations of 
three hours or more. This technique is often used in prac- 
tice where collection subsystem characteristics often 
dictate a finite set cf possible collection allocations (and 
would therefore dictate estimates of a . . in the basic 
model). This system appears to provide a reasonable 
approach to the problem of a priori estimation of a^ . The 
wide range cf possible collection resource allocation esti- 
mates is narrowed by subsystem operating procedures, norms, 
and standards. Individuals are then in a better position to 

provide more accurate estimates of a... 

il 

From this discussion we conclude that the estimate 
cf the amount of subsystem collection hours associated with 
collection subsystem j in contributing to the satisfaction 
cf collection requirement i (a—) can be provided by the 
specific subsystem operators, furthermore, such an estimate 
is highly dependent upon the manner in which a specific 
collection subsystem can allocate collection resources. 

^ • Object ive Fu n ction 
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The second major component of the objective function 

is E. . 

Ep = The aggregated effectiveness of reguirement i with 
respect to all collection subsystems. 

This component, in turn, is dependent upon several ether 
factors which will be developed in the following paragraphs. 
Ihe first factor in the determination of aggregated effec- 
tiveness pertains tc the effectiveness of a collection 
subsystem j. In attempting to satisfy a given collection 
reguirement i, collection subsystem j interacts with seme 
measureable form of enemy activity. For instance, a pheto 
reconnaissarce platfcrm takes a picture of a location on the 
battlefield (presumed to be located in enemy territory) . A 
communications intercept platform monitors certain frequen- 
cies cn the electr omagnetic spectrum (hopefully the enemy is 
transmitting information of value which friendly forces can 
detect on such frequencies) . Many things can happen which 
can prohibit these interactions from occurring. In the 
photo reconnaissance situation, for example, the platfcrm 
may breakdown prior tc its TOT or worse yet may be shot down 
by the enemy. In the communications intercept case the 
enemy may decide to eperate on radio silence (i.e. not use 
those monitored frequencies at all). In both situations, 
the collection effort would be unsuccessful. As a matter of 
fact, the intended interaction with enemy activity did not 
occur at all (or we cannot detect whether it occurred) . 
When this happens we say that the collection mission has 
failed. There exist measures or estimates of these sorts of 
failures with respect to different types of collection plat- 
forms and subsystems under a variety of threat and opera- 
tional conditions. These measures are often represented as 
a probability. In our situation we are specifically inter- 
ested in the probability of mission failure (where mission 
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e information/data, etc. that the 
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ith the probability of success 
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Ihe second factor w 
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actual satisfaction cf the 
that a collection sutsyste 
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The term f . . is defined as: 

f^j = Ihat fraction of re 
fied if collection 
it intends to col 
requirement i. 

Note that the term f • • i 
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tion requirement consists o 
referred to as quality su 
ters) . The aerial reconna 
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successfully performed its 
data it intended to collect 
calculated value for f — wo 
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of the value of f^j is 



at collection subsystem j will 
it intends to collect in 
fy a requirement i. 

does not imply that the collec- 
s able to satisfy the collection 

hich is important in determining 
ollection subsystem pertains to 
collection requirement. Recall 
m may be capable of satisfying 
any given collection requirement. 

quirement i which can be satis- 
sutsystem j collects the data 
lect in attempting to satisfy 

s of the form of a conditional 
er the example in which a ccllec- 
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breguirements in previous chap- 
issance system, in this example, 
se four subreguirements if it 
collection mission (collected the 
). Thus, in this example, the 
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of requirements the determination 
a fairly simple matter (as 
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demonstrated in the example in the preceeding paragraph) . 
For such simple classes of reguirements and various types of 
collection subsystems it would he theoretically possible to 
develop ncrms and standards useful in determining such 
values. Fcr example, in the class of simple targeting 
reguirements cited in an earlier paragraph, only three items 
of information were required for satisfaction - target 
description, nature, and level of protection. For this 
simple class of reguirements the aerial reconnaissance 
subsystem is capable of satisfying all of the subreguire- 
ments given that the intended collection occurs. Therefore 
its f^j value with respect to simple targeting requirements 
is one. For more complicated classes of collection reguire- 
ments we wculd expect that the determination of f^j will be 
more difficult. In the basic model under consideration it 
will be assumed that it is possible to determine the values 
of all f — for the reguirements under consideration. 

The term which represents the relationship between 
satisfaction of a given collection requirement i by collec- 
tion subsystem j can now be identified and examined. The 
term e ^ j is defined as expected level of requirement satis- 
faction as given by: 



e . . 

13 





(eqn 5.5) 



This term can be interpreted in the following manner: If 
collection system j is allowed to allocate resources toward 
the satisfaction of requirement i, then e— represents the 
level cf collection requirement satisfaction we might expect 
to receive in return. The calculation of e^j is of the form 
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of a probability multiplied by a conditional expected frac- 
tion (both values are bounded by zero and one) yielding an 
expected value. Thus e^ is also bounded by zero and 1. 

The value e ,- 4 represents the level of requirement 
satisf action we would expect to receive by allocating 
resources from a single collection subsystem j against a 
single collection requirement i. Our problem, however, 
involves multiple collection requirements and subsystems. 
In order to solve this problem we must be able to aggregate 
over both requirements and subsystems. We will first 
attempt to deal with the total effectiveness of a given 
collection requirement. 

a. aggregation Over Collection Subsystems 

let E ^ be defined in the following manner: 

E . = The expected fraction of requirement i satisfied 

i 

by all collection subsystems (j = 1 ,...,m). 



This study will address two possible methods of obtaining 



the total aggregated effectiveness - denoted E. . 

The first approach to the calculation of E 



through the simple summation of e . . 

i' i] 

denoted E ^ . Specifically: 



is 



values and will be 



m 



E. = 

1 



2 

j - 1 



e . . d . . 
id i] 



(eqn 5.6) 



Under most envisioned circumstances one would not expect to 
ever he able to satisfy a requirement by any factor greater 
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than 100^. Unfortunately, this specific method of aggrega- 
tion allows for that to occur. Consider the simple example 
in which a given collection requirement can be satisfied by 
two collection subsystems. In this example the value of e 
is .75 and e^ is • 50. If the decision is made that both 
subsystems will allocate their resources toward the satis- 
faction of that ith requirement, then according to the 
summation procedure the total expected level of satisfaction 
for that ith requirement would be: 



i 

i 



2 

e . .d . . 

3 = i 




( e 



-hi* 



+ (0 

i2 



d i2 ) 



(eqn 5.7) 



(.75 • 1 ) + (.50 



1) 



= 1.25 



This value seems difficult to interpret given the preceeding 

1 

development. An obvious explanation for the E. value 

1 

greater than one is that there must exist some amount of 
collection subsystem overlap. This overlap is referred to a 
redundant coverage. The summation technique would provide 
more reasonable results if only one collection subsystem 
were allowed to allocate resources toward the satisfaction 
of a collection requirement. If this condition were to be 
applied to the example above then the collection requirement 
in guestion would have a total expected level of 
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- What types of communications systems is the unit 
located at ABxxxxxx using? 



It is likely that this requirement might be satisfied by 
tasking sensors which could detect and locate communications 
emmitters cn separate and non-overlapping portions of the 
electromagnetic spectrum. Thus, no more than one sensor or 
subsystem could satisfy the same portion of the collection 
requirement. The f • ^ values associated with this require- 
ment and their respective subsystems would be mutually 
exclusive and the summation methodology would be a reason- 
able method of aggregation. 

A second drawback to the summation method of 
aggregation is that there exists, using this technique, no 
way to represent, in a continuous sense, decreasing marginal 
returns. Specifically, the summation function tells us that 

more resource allocation to requirements with high values of 

r 

E. is always a good thing to do. In fact, we can see that 
there are many circumstance s where this action is net a good 
thing to do. Clearly, there exists some point in time in 
which additional resource allocation to satisfy a require- 
ment which may already be totally satisfied is not produc- 
tive and in fact is wasteful. 
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asons of interpretability and 
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s we reject it as a method of 
over collection subsystems. The 
provides a solution to these two 



The primary drawback to the previous aggregation 
scheme is that under certain conditions it would produce 
aggregated effectiveness values which were difficult to 
interpret and could not adequately represent decreasing 
marginal returns associated with the allocation of collec- 
tion resources. A more meaningful scheme would be one in 
which the total expected level of satisfaction for a given 
requirement (when collected against by multiple subsystems) 
would be bounded by one and could thus be more easily 
compared with percent levels of requirement satisfaction 
(i.e. 1005! satisfaction would be the maximum attainable 

value for E ) . Furthermore/ we would like to see the total 
expected level of requirement satisfaction increase as more 
collection subsystems are tasked toward the satisfaction of 
a given collection requirement but not necessarily in a 
totally linear fashicn. In other words, two collection 
subsystems ought to provide more satisfaction than one but 
they could never provide more than 100% requirement satis- 
faction. Intuitively we would expect that the lower bound 
on the expected level of requirement satisfaction (in the 
case where two subsystems were tasked to satisfy a given 
collection requirement) would be the maximum of (e,--, , e^ 9 ). 

If we interpret the value of (d . . x e.. ) as the 
probability of achieving satisfaction of requirement i by 
allocatirg collection resources from subsystem j then the 
term: 
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(1 



not achieving 



d i ^ e £ j ) = The probability of 

satisfaction of requirement i by 
allocating collection resources from 
subsystem j (given that we decide to 
allocate resource from j) . 

If we also consider that the operation of one collection 
subsystem is independent of the operation of another then 
the probability of net achieving satisfaction of requirement 
i by allocating collection resources from m collection 
subsystems can be represented in the following expression: 

m 

TT d - (sgn 5.8) 

j = 1 



Cf course, the probability of achieving satisfaction of 
requirement i by allocating collection resources from m 

collection subsystems is actually E^ which, in turn, is 
given by: 



2 

E . 

i 



= ( i 



m 

TT ( 1 - d . . e . . ) ) Vi (eqn 5.9) 

i] i] 

j = 1 
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The primary cause for concern with respect to 
this aggregation technique is the assumption of independence 
cf collection subsystems. We are concerned that two or more 
subsystems, in collecting information pertaining to the same 
requirement, might be dependent upon one another. This 
possibility does exist. Say, for instance, an aerial recon- 
naissance platform overflies an enemy position on a collec- 
tion mission. The enemy, in response to that overflight, 
ceases all electronic emission activity (fearing the plat- 
form was capable of detecting such activity) . An electronic 
intercept platform collecting that enemy unit's emissions 
would be negatively affected by the aerial reconnaissance 
platform’s overflight. 

Examples such as these are hard to envision but 
in fact much of the intelligence operation planning process 
is devoted to insuring that two or more collection opera- 
tions do not conflict or interrupt one another. The point 
to be made is that this method of aggregation seems to be a 
reasonable approach as long as the collection subsystems 
involved are independent of one another. vfr 

b. Aggregation Over Collection Eequirera ent s 

We must new concern ourselves with the second 
aggregation problem. How do we combine 2? for all collec- 
tion requirements under consideration? Let E be defined in 
the following manner: 

E = Total level cf requirement set (n requirements) 
satisfaction given collection allocation from m 
subsyste ms. 

n m 

E = Y v.( 1 - TT (1 - d . . e . . ) ) (eqn 5.10) 

Z i i] i] 

i = 1 j = 1 
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ic Model 



The basic model as formulated will attempt to allo- 
cate collection subsystem resources to requirements in a 
manner which provides the biggest return in overall E (total 
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aggregated level of requirement satisfaction) for a given 
allocation (assuming a feasible solution can be found for 

the program). Thus, resource allocations will be made to 

2 

those requirements whose E. contribute the most to the 

2 

objective function. The amount of E . which any single 
requirement can contribute to overall satisfaction (E) 
increases as more resources are allocated toward the satis- 
faction of the requirement but reaches a limit of one. This 

2 

characteristic results from the manner in which E is 

i 

calculated. Recall Equation 5.9. As more collection 
resources are allocated to the satisfaction of requirement i 

the product term in Equation 5.9 becomes small. The term 

2 

El , therefore, approaches one as a limit in such circum- 
stances. Thus, as mere resources are allocated the marginal 
return of such allocation decreases until such time as allo- 
cation tc a different requirement becomes more attractive. 

Cne disturbing aspect of this basic model is that we 
have no guarantee that all requirements in the given set 
will be satisfied by the optimum resource allocation scheme 
calculated by the program. For instance, allocation of 
collection resources to a given requirement may never be 
more attractive (contribute more to the maximization of the 
objective function) than allocations to other collection 
resources. In such a situation this program would ignore 
requirement i in favor of allocations of resources to ether 
requirements. An additional limitation (somewhat related to 
the first) is that we have no control over the level of 
satisfaction of any given or set of collection requirements. 
In other words this program cannot deal with requirement 
priorities. 
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E. 7 ABIATICNS OF THF BASIC MODEL 

Recall the basic model developed in the first section of 
this chapter: 



MAXIMIZE: 



n 




v . E . 
1 1 



SUBJECT TO: 



n 




i - 1 



(eqn 5.11) 



d . . = 0 or 1 
il 



i 



1,...,n (i is the index 
ments. There are a total 
ments considered in the 
basic model) 



for collection reguire- 
of n collection reguire- 
requirement set of the 



j = 1,...,m (j is the index for collection subsys- 
tems. There are a total of m collection subsys- 
tems considered in the basic model) 




The decision to allocate collection resource j tc 
collection requirement i (0 = no, 1 = yes). 



a.. = The amount cf collection resource j allocated 

il 

toward the satisfaction of collection requirement 
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i if d-^ = 1 (units are subsystem collection 

hours - hrs) . 

bj = lotal amount of subsystem j collection resources 
available for use is satisfying the set of collec- 
tion requirements n . 

v^ = Relative importance associated with requirement i 

(priority). Requirement priority will net be 

considered in the basic model and therefore 

v^ = 1 in the basic model. Requirement priority 

will be addressed in Section 3.2 of this Chapter 

where values of v. will be allowed to vary. 

i J 

= Expected fraction of requirement i satisfied by 
those collection subsystems (j = 1,...,m) tasked 
to satisfy that requirement. 



1 . Ins uri ng L evels of R eg uir emen t S atisfac tion 

A primary drawback to the basic model can be handled 
using a similar problem formulation. If possible we would 
like to be able to satisfy all collection requirements in 
the total set. In order to insure this we could add to the 
above formulation additional non-negativity constraints. A 
modified formulation containing such restraints is described 
below : 



MAXIMIZE: 



E = 



n 

I 

i - 1 



v . E . 

l l 



WHERE : 




( 1 - d . .e. . ) 

i] i] 
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1 



2 



SUBJECT TO: 




eqn 5. 12) 



n 



I 




d 



0 or 1 



k^ = Ad aspiraticD level of individual requirement 
satisfaction . 



for all collection requirements i (at least some minimum 



however, of the ultimate level of requirement satisfaction. 
Cne can easily imagine an iterative type process which would 
increment the value cf k^ between successive runs of the 
program until a feasible solution can no longer be obtained. 
The gcal of this iterative process would be to determine the 
highest levels of satisfaction at which all requirements 
could be feasibly satisfied. One must realize that the 
final levels will be dependent upon the scaling factors (k^ , 
k 9 ,..., k R ) imposed by the program. 



and the basic model outlined in Section A of this Chapter. 
The basic model is guaranteed to have a feasible solution. 
All requirements in the set may not be satisfied to a mini- 
mally desireable level but the model will find a solution. 
The constraints placed upon the basic model (as outlined in 
this section) may eliminate the possibility of finding a 
feasible resource allocation scheme. 

Given this fact it may be reasonable to approach the 
solution cf this problem in an iterative manner. 



2 



This formulation will insure levels of E. greater than k 

l 



level of requirement satisfaction). We remain uncertain. 



There is a fundamental difference between this model 
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MAXIMIZE: 



SUBJECT TO: 



m 



(1- TT ( 1 - d . . e . . ) ) > Zk . 

i] i] i 

j = 1 



n 



X' d . . a . . < b . V j 

Z, ig ig g 



i =• 1 



(egn 5. 13) 



d . . = 0 or 1 

ig 



Zk i = Ihe 



highest attainable 
requirement satisf a ction . 



level of 



individual 



Ihe value Z in this formulation serves as a scalar multiple 
of the individual requirement aspiration levels (k^) . Thus, 
this formulation maximizes the value of Z and in doing so 
maximizes the the level of individual requirement 
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satisfaction subject to the aspiration levels (k]_, k^,..., 

k^ ) imposed on the pregram. 

2. Req uir ement Priorities 

The prioritization of collection requirements serves 
as an important management function and, as Appendix A 
suggests, as a possible means of providing intelligent 
control of the collection process. We know that it is 
possible tc prioritize a given set of collection require- 
ments (see Appendix A). We must be able to incorporate seme 
such ranking scheme into the optimization process. 

There are two approaches toward modifying the basic 
model once we have decided that one requirement may be mere 
important than another. The first approach is to insure 

that the more important requirement is allocated collection 

resources in such a manner that its level of satisfaction 

2 

(E,- ) is greater than that of the less important require- 

ment. The second approach is to insure that the objective 
function of the model takes into account the fact that one 
requirement is more important than the other when it maxim- 
izes the overall level of requirement set satisfaction ( E) . 
Each cf these two approaches are addressed in the following 
sections. 

a. Prioritizing Using levels of Requirement 

Satisfaction 

There are several approaches to insuring mere 
important requirements acheive higher levels of requirement 
satisfaction than less important requirements. Taking the 
formulation developed in Equation 5.12: 



MAXIMIZE: 



Tl 

E 2 V 1 

i - 1 



m 



TT a 



d . . e . . ) ) 

il il 



SUBJECT 



'i(.h). > . 



(eqn 5. 14) 
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> . 



n 

i = 1 



d. .a. . < b . V i 
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C or 1 



He have modified the program at Equation 5.12 by creating 
constraints which correspond to the levels of priority in 
cur priority system (in this case there are three priori- 
ties - high (h) , medium (m) , and low(l)). Specifically, we 
have determined that we desire that the high priority 
requirements in the tctal set be satisfied at the . S level, 
medium priority requirements at the .7 level, and low 

priority requirements at the .5 level. Certain aspects of 
this formulation cause concern. That concern revolves 
around the relationship between low, medium, and high 

priority requirements. For example, in the above formula- 

2 

tion we require for all low priority requirements must 

he greater than or equal to .5 and those for medium priority 
requirements be satisfied at a level greater than or equal 
to .7. As a result of these constraints we should expect to 
see that high priority requirements are satisfied at values 
greater than or equal to the value .9. What we do not know 
is what will happen to our overall E (and satisfaction 
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levels for high and medium priority requirements) in the 
event we lower the constraints for low priority requirements 
from .5 to value .2. Similarly we don't know what will 
happen if we merely drop one low priority requirement from 
the total set of requirements. 

This observation suggests that we examine the 
sensitivity of the manner in which we allocate resources to 
collection requirements. Ore way to accomplish this sort of 
examination is to approach the prioritization of the collec- 
tion requirement set in a somewhat different manner. 
Suppose we partition the rank ordered requirement vector (R) 
returned by the process outlined in Appendix A into three 

sections R , R , R . High priority requirements are 

1 m h 

elements of R^, medium priority requirements are elements of 
R^, and low priority requirements are elements of R . It is 
certainly desireable that high priority requirements (R ) be 
allocated resources in such a manner that their respective 
levels of satisfaction are high. To insure that this can be 
accomplished, irrespective of all R^ and R 1 requirements, we 
formulate the following: 
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(eqn 5. 15) 
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< b . 



d ;j = 0 or 1 

If such a program proves to provide a feasible solution then 

2 

we will knew exactly what levels of satisfaction (E^ ) for 

all retirements and that those regui re ments we identified 

2 

as having a high priority will have E^ values of at least 
.9. The next step in the iterative process is to add levels 
of satisfaction constraints to the program for these 
requirements we have identified as having a medium priority. 
This formulation would appear as follows: 
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(eqn 5.16) 



m 



E. = C 1 - TT (-1 - d-.e..)) 
j = 1 



n 



y d. .a. . < b . Vi 

L i] i] 3 J 



i - 1 



= 0 or 1 



d. . 



94 



If this "upgraded" program provides a feasible solution we 

know that requirements which are elements of R, and R will 

3 n m 

be satisfied at levels of .9 and .7 respectively and that 
all other requirements will at least be minimally satisfied. 
Cnee this iteration has taken place it is possible to 
examine the sensitivity of adding the R m level of satisfac- 
tion constraints. If, for instance, we fail to find a 

feasible solution after the addition of the R constraints 

m 

then we know that this infe asibility was caused by the addi- 
tion of the constraints. We may also discover that by 
levying these constraints we have reduced the levels of 
satisfaction of the lower priority requirements (R. ) to such 
a level that resource allocation to them would not be worth- 
while. We may also discover that the solution is satisfac- 
tory and continue onto the final iteration of the process 
which would be to add R^ level constraints. At this point 
in time the program becomes identical to that shown at 
Equation 5. 14. 

There are many advantages to this iterative 
approach. It is extremely flexible and could easily be 
adapted to a wide variety of prioritization schemes. In the 
early stages of the iterative process there is a greater 
liklihood of finding a feasible solution to the problem 
because the constraints on the program are less severe than 
those associated with the formulation at Equation 5.14. 
However, a feasible solution to a problem formulated with 
such constraints (as alluded to in previous discussion) is 
not guaranteed. Additionally, this iterative process 
requires time and interaction with human decision makers. 
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t. Prioritization Using the Objective Function 

Recall the term v _• in the objective function of 
the basic model. It was defined in the following manner: 

v,- = Ihe relative importance associated with a given 

collection requirement i. 

In the previous model development we let v egual one for 
all i. In other words we considered all requirements to be 
cf egual importance. In this portion of the model we have 
decided that all requirements are not of egual importance. 
■Therefore, the objective function of the basic model consid- 
ering requirement priorities would look very similar to the 
initial formulation: 



n 



MAXIMIZE : 
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v. E . 
1 1 



i = 1 



n 



SUBJECT TO: 





i = 1 




(egn 5. 17) 
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l n - 



= A scalar representing the priority value cf the 
ith requirement. 

In this case the values of would not all be equal to one. 

There are numerous ways in which the values of 
v : can he scaled. The most appealing method is to let the 

most important requirement in the set equal one and all 
others (in rank order) be values less than one but greater 
than zero. In the event many requirements were being 
considered in the set it may be wise to group those require- 
ments of similar importance (i.e. in groups of high, medium, 
and lew importance) and weight the groups appropriately. 
The effect cf this sert of scheme is that the value of E is 
increased to a greater degree by higher priority (more 
heavily weighted) requirements than lower priority require- 
ments. Thus, the program in its allocation process will 
emphasize the satisfaction of those requirements of higher 
priority. This type of formulation will lead to a feasible 
allocation solution to the model considering requirement 
priorities. However, once again we are uncertain as to the 
minimum levels of requirement satisfaction which will be 
obtained using such a formulation. 

The problem of requirement priorities can be 
addressed through modification of the basic model in two 
basic manners - by adding constraints to the basic model, or 
modifying the objective function of the basic model. Each 
technique has its theoretical advantages and disadvantages. 
The usefullness of either approach would, therefore, be 
determined by the actual situation in which they might be 
applied . 

3 . Red undancy of Colie ction C ove rage 

Redundancy of collection coverage is an important 
collection management tool. It is often wise to insure that 
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(egn 5. 18) 



could be added to the formulation outlined at Eguation 5. 14. 
Cne must remember that the more restraints which are added 
to a program decrease the chance of discovering an optimum 
solution and may decrease the guality of a feasible solu- 
tion. Thus a more reasonable approach to the redundancy 
issue might also involve an iterative and interactive 
approach. For instance, once the user is satisfied with the 
resource allocations with respect to the priority of the set 
of collection reguirements (as discussed in previous para- 
graphs) , he might then examine those allocations to deter- 
mine where redundancies of coverage already exist. Recall 
that an increase in levels of satisfaction (E^ ) may be the 

result of the allocation of multiple collection subsystems. 
As a result, some of the collection reguirements may already 
be satisfied by multiple subsystems in the existing feasible 
solution. Furthermore, those most likely to have such 
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multiple coverage are the more important requirements (from 
a priority point of view). If the decision maker is satis- 
fied with the allocation scheme no further constraints need 
he applied to the program. However, if unsatisfied, the 
decision maker can apply constraints (such as those shown at 
Equation 5.18) in a piecewise fashion, compare new alloca- 
tions with previous allocation schemes, and decide which set 
cf resource allocations is better suited to the collection 
problem at hand. 

h . Dse of a Conti nuous Decision Vari able 

Ehen we decide that the collection subsystems in the 
system can allocate collection resources in a continuous 
manner (as opposed tc allocation of resources in discrete 
packages) then the continuous decision variable model 
described below is useful: 
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(eqn 5. 19) 
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1,-..,m (j is 


the 


in dex 


for collection 


subs ys- 


terns. There are a 


total 


of m collection 


s ubsys- 


terns considered 


in 


the mode 


1) 





The amount cf collection resource j allocated 
toward the satisfaction of collection requirement 
i (units are subsystem collection hours - hrs) . 

= Total amount of subsystem j collection resources 
available for satisfying all collection require- 
ments (i = 1 , . . . ,n) . 

v^ = Relative importance associated with requirement i 
(priority) . 

3 

= Expected fraction cf requirement i satisfied by 
all collection subsystems (j = 1,...,m). 

There is a difference between this model and 
previous models developed in the study. Before, we were 
concerned with the management cf collection resources given 
a way in which we were allowed to allocate each resource 
(a,- j ) . Thus, we were mixing fixed amounts of assets to 

obtain an optimal solution. In the continuous model we are 
managing not only the mix of assets but also the quantity of 
asset used in the mix. Thus, the continuous decision vari- 
able model should be viewed as a much more absolute model in 
terms cf controlling the collection subsystems. 

Eecause we are controlling how much of a given 
resource ought to be allocated toward the satisfaction of a 
given requirement the the binary decision variable d^4 and 
the predetermined and fixed amount of collection resource 
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a^ are not included in the continuous decision variable 
model. In their place we have introduced the continuous 
decision variable x,. 4 (defined above). 

Because the amount of collection resource which can 
be allocated toward the satisfaction of a collection 
requirement is now variable we must re-evaluate the defini- 
tions of quantities which are dependent upon x^. 

The e term, previously defined for the discrete 
(basic) model was: 



e . . 
ij 






f . . 

id 



(eqn 5.20) 



It was interpreted to be the level of satisfaction with 
respect to requirement i we might expect to receive in the 
event collection resource j were allocated toward require- 
ment i. In the discrete model situation a„. ^ was predeter- 
mined and fixed. In the continuous decision variable mcdel, 

x . . is a variable and thus p.. , f . . , and consequently e • . 

l] *l] 'id a j 13 

are all functions of x... The term e,„..v is defined as 

id (X13) 

follows : 



e (.Xij) = p CXij) 



x (Xij) 



(eqn 5.21) 



p (xij )= The probability that collection subsystem j will 
collect the data it intends to collect in 
attempting to satisfy requirement i expending 
x^j collection resources. 



( X i j ) 



(f 



(Xij) 



That fraction of requirement i which can be 
satisfied if collection subsystem j collects the 
data it intends to collect in attempting to 
satisfy requirement i allocating x^4 collection 
resources. 

The expected fraction of requirement satisfaction 
is now a function of hew much resource we allocate 



towards the satisfaction of a given intelligence require- 
ment. Onder most circumstances we would expect that the 
fraction of the requirement satisfied would generally 
increase (from some minimum value) to a maximum possible 
fractional level of satisfaction. It is hard to imagine a 
case in which more collection resource allocation would 
actually decrease tie expected level of requirement satis- 
faction. Thus, this function is assumed to be monotonic 
nondecreasing. 

The probability that a collection subsystem collects 
the data it intends to collect (P(xij)^ i s a ^ so a function 
of x... The possibility exists, given this functional rela- 
tionship between P(xij) an< ^ x ij' that the probability a 
collection subsystem collects the data it intends to collect 
may decrease as a function of x^j. Consider the example of 
an aerial reconnaissance sortie over an enemy position (i.e. 
a threat exists to the survivial of the platform). To 
(the amount of collection resource allocated) 



increase x 



^3 

this platform may have to overfly the enemy position several 
times. In doing so the platform increases its vulnerability 
to the enemy threat and reduces its chances of returning its 
collected data to the subsystem operators. Thus, as the 
collection platform allocates more resources toward the 
satisfaction of the requirement its resulting P(xij) value 
decreases. Accordingly, the value of e (xij) w ki c h depends 
upon p 



could also decrease as x-. 

(Xij) 13 



increases . 



This 
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observation is difficult to interpret - as lore collection 
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surveillance example with discrete rather than continuous 
decision variables. 

The observations and discussion in the previous 
paragraph allude to the difficulty in interpreting the value 
F(Xij) ^- I] t ^ ie continuous decision model. Specifically, what 
type of collection subsystems (platforms) are suited to such 
a model and how do we determine P(xij) ^ or an unknown 
x— ? The continuous decision model is best suited to 
those collection subsystems which are oriented towards a 
surveillance activity. In other words, those subsystems 
which mcritcr some form of enemy activity for a period of 
would therefore itself be a function of time on 



time (x 






target - TOT). The requirements such subsystems might be 
tasked to collect information cn would probably be somewhat 
time dependent. For instance, a SLR (side looking radar) 
might he asked to determine the direction of enemy advance. 
The probability that the SLR subsystem could determine that 
information would increase as TOT increased (and conseq- 
uently x— increased). Determination of these sorts of 
]?(Xij) values would be difficult and probably could cnly be 
addressed with the use of empirical data or perhaps from a 
simulation. 
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In this model we are determining which collection 
subsystems ought to allocate resources to which requirements 
and also how much of those resources ought to be allocated 
towards the requirement. This is a fundamental difference 
from the basic (discrete) model. It (the continuous mcdel) 
can be viewed as a relaxation of the basic model in that we 
are nc longer concerned with collection resource packaging 
constraints but rather in allocating collection resources 
along a continuum. 



104 



VI. APPLYING THE INTELLIGENCE COLLECTION MANAGEMENT MODEL 
A. I NTBCDOCTION 

Three important assumptions were made in the 
development of the basic model. They were: 

- Cnly a fixed number of collection requirements (n) 
could be considered in the model. 

- Cnly a fixed number of collection subsystems (m) could 
be considered in the model. 



- All requirements will have resources allocated toward 
their satisfaction at the same time. 

With these assumptions we were able to develop a series of 
models which optimized the allocation of collection 
resources for a given set of collection requirements. The 
objective of this chapter is to illustrate how these assump- 
tions are related to the realistic collection management 
environment and how the optimization models developed in 
Chapter Five can easily be modified to adapt to such an 
environment. 

E. TEE COLLECTION HABAGEMEHT ENVIRONMENT 

In the realistic collection management environment 
collection requirements enter the system, resources which 
seem suitable are tasked toward their satisfaction and if 
the requirements are satisfied they leave the system (ether 
options are addressed in Chapter Two). Rarely, if ever, are 
collection requirements viewed in groups or sets as our 
models reguire. A multiserver queue would be a more apt 
description of the process. 
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Similarly, collection subsystems are rarely considered 
as a set. Either a subsystem available for tasking is suit- 
able (can collect what the reguireaent indicates is neces- 
sary to collect) for satisfying (or at least partially) a 
requirement or it is not. If the subsystem is suitable it 
is tasked and if it is not suitable it is not tasked. On 
occasion, if there is sufficient justification, additional 
collection resources may be requested (and perhaps received) 
for use by the unit. Similarly, additional (and unplanned 
for) collection resources will sometimes be made available 
by a higher authority for use by the unit's collection 
system. 

The entire allocation process is affected by time 
constraints associated with both the requirements anc the 
collection subsystems (see Chapters Three and Four) . The 
hectic pace of matching requirements with suitable and 
available platforms given a wide variety of deadlines rarely 
allows for more than a momentary consideration of the best 
allocation for a set cf collection requirements. 

It appears, therefore, that the assumptions we made in 
developing the optimization models counter our observations 
cf the realistic collection management environment. The 
next section of this Chapter illustrates how, through a time 
analysis of all collection requirements and minor modifica- 
tion tc the structure of the basic model, these problems can 
be easily overcome. 



C. TIHE OEEERING OF COLLECTION REQUIREMENTS 

If our models are to be useful they must be adapted to 
the collection environment. To do this we must be able to 
identify, from the environment, those requirements which 
will be allocated collection resources. We know that the 
number cf requirements in our imagined queue is variable and 
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tj_j = The tasking deadline associated with requirement i 
and subsystem j. That point in time beyond which 
subsystem j cannot be tasked to satisfy require- 
ment i. 



If we are considering a total of m subsystems (all of which 
could contribute to the satisfaction of requirement i) and 
none of the time restraints associated with those subsystems 
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vere identical then there would exist a maximum of m tasking 
deadlines associated with r eguir ement i. We are concerned 
with identifying that t_- j value which, if met, would not 
exclude the use of any of the subsystems which can 
contribute to the satisfaction of requirement i from doing 
so. That value will he referred to as t c ^ : 

t . = The latest point in time such that all subsystems 

which can contribute to requirement i can be 
tasked to do so. 



or, 
t = 



given that all 
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(eqn 6.2) 
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D. ALLOCATING COLLECTION RESOURCES 
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the basic model was that all collection 
consideration will have collection 
toward their satisfaction at the same 
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time. Ad examination of the realistic setting clearly indi- 



secticn developed a requirement scheduling method which 
would help the decision maker determine which collection 
requirements in the collection system the optimization 
models ought to include. A reasonable approach toward allo- 
cating collection resources is to allocate (based upon the 
output of the optimization model) only to those requirements 
whose t c j_ values are near, update the model with respect to 
current conditions (new incoming requirements, modified 
amount of resources available, and new t . values), and 
optimize over the new set of conditions. The allocation 
process would lock like that shown in Figure 6.1. 

This allocation process allows for the variation of the 
amount of collection resources considered in the optimiza- 
tion models and for the piecewise allocation cf such 
resources toward the satisfaction of collection require- 
ments. The success of this process, however, is dependent 
upon several factors. A factor of primary importance is 



process can provide a feasible allocation plan in a timely 
manner. Additionally, we are assuming that necessary inputs 
(updates of current conditions) can be provided to the 
process . 

It is important to note that the models can be applied 
to situations in which the amount of available resources are 
variable and actual resource allocations are made in a 
piecewise fashion. This is accomplished by embedding the 
optimization model in an iterative allocation process rather 
than through any modification of the actual model. 

The optimization models developed in Chapter Five appear 
to be more flexible than initially envisioned. They can be 
adapted to the more realistic collection management setting 
in which bcth requirements and resources are variable and 



cates that this assumption is unreasonable. The previous 



whether or not the optimization model 




in the 
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Start 







Figure 6.1 Collection Besource Allocation Process. 

collection allocations are made only when required (and in 
accordance with the current battlefield situation) . 

E. SIZE OF THE CPTIHIZATION MCDE1 

It is important to estimate the size of the collection 
management problem. In particular we would like to know how 
many collection subsystems and requirements will be consid- 
ered in the optimization models developed in Chapter Five. 
An estimation of this nature is dependent upon the echelon 
of friendly force of interest. This study will, therefore. 
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focus on the maneuver division in estimating the size cf the 
various components of the collection management problem. 

The collection subsystems available to a division 
generally fall into two classes: 

- organic: Those belonging to the division. 

- ncn-organic: Those which the division can (in certain 

situations) task for use but do not own. 

Divisions are virtually free to operate their organic 
subsystems (IMINT, SIGINT, and HUMINT) in accordance with 
their battlefield role or mission. However, the division 
will be granted access to non-organic subsystems (which 
correspond closely tc those found at the division but are 
usually more specialized) only when its battlefield mission 
is of relative importance (i.e. the unit is in contact with 
enemy forces). Thus, the number of collection subsystems 
available tc a division varies (primarily as a function of 
its battlefield role) from an organic number of three tc a 
maximum number (both organic and non-organic) of twelve. 
The availability of both organic and non-organic collection 
subsystems is also dependent upon environmental and opera- 
tional factors (primarily weather and threat) . These 
factors would, of course, reduce the total number of 

subsystems available to the division. 

An intelligence system of a division is normally 
concerned with approximately 15 to 30 standing intelligence 
requirements (referred to as Essential Elements of 

Information and Other Intelligence Requirements - EEI/OIR) 
and perhaps 15 to 3C user generated intelligence require- 
ments.. Each of these intelligence requirements are vague 
and can be decomposed into several collection reguirements 
(i.e. the SIGINT collection subsystem would refer to these 
collection requirements as SIGINT Indicators) . The number 
of collection reguirements in the collection system is also 
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battlefield role and disposition 
ould expect that the number of 
se as more organic forces are 
the enemy. Given a particular 
number of collection requirements 
r would fall between 30 and 200. 

it is possible to address the 
nagement problem. Estimates of 
mum size problems can easily be 



TABLE I 

Size of the Collection flanagement Problem 
Leve ls 

Maxi mum M inimum 



Reqts 


(r) 


250 


Subsys 


<£) 


12 



provided: The implications of these estimated values are 

interesting. For example, in the discrete decision (basic) 
model under maximum conditions (n = 250 and m = 12), there 

would exist 3000 (250 x 12) decision variables (d^ 4 in the 
discrete model, xij in the continuous model) to consider. 
This assumes, of course, that each collection subsystem is 
capable cf contributing to the satisfaction of each collec- 
tion requirement. The point to be made is that the 
complexity of the problem increases dramatically as more 
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collection subsyste ns and requirements are added tc the 
collection system. This observation highlights the need for 
us tc consider all reasonable methods of reducing the 
complexity of the problem ( such as the reduction of the set 
cf requirements n tc n as discussed in Section C of this 
Chapter) . 



F. CCNCIOSIONS AND EFCOMM E NDATIONS 

This thesis has developed a structure for and examined 
the functions of a generalized intelligence collection 
system. Traditional approaches toward the management of 
collection requirements (identified in the study as the 
primary focus of the collection system) were shown to be 
inefficient and less controlled than desired. It was also 
shown that with minor restructuring of some functions within 
the collection system and development of the capability to 
estimate subsystem operational capability components (p_. . 
and ■£ — )* operations research techniques could be applied to 
a simplified version of the collection system problem, that 
being the allocation of scarce collection resources toward 
the satisfaction of collection requirements. 

A mathematical optimization model of this simplified 
process was developed. Modifications of this model were 
explored with respect to important intelligence collection 
related concepts such as priority of requirements, redundant 
collection coverage, and applicability of the optimization 
model to various types of collection subsystems. 

Future efforts in this area should focus on the 
following topics: 

- Solution algorithms to the models developed in Chapter 
Five. 



- Ose cf the models as decision aids in wargames and as 
resource allocation algorithms in battlefield simula- 
tions. 
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req uirements in terms of the 
in Chaffer Five. 
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APPENDIX A 



A METHOD OF HANKING COLLECTION REQOIREMENTS 



Collection systems have traditionally prioritized 
collection requirements according to SOP's. Each unit's SO? 
is different from another. They all, however, prescribe 
what a requirement priority will be given the existance of 
certain conditions on the battlefield. For example, an SOP 
may require that collection requirements from support units 
(non-combat forces) cannot be submitted as high priority 
requirements. The battlefield condition in this example is 
the nature cf the friendly unit submitting the requirement. 

Collection requirements are rarely analyzed in groups. 
Thus, or.ce a requirement (and its priority as determined by 
the SCP) are validated (approved by the collection system 
decision maker) they are fcrwarded for action to the 
collection subsystems. In the restructured approach 
discussed in this thesis a set of collection requirements 
are decomposed at the system level prior to being fcrwarded 
to the collection subsystems for action. Thus, it is 
feasible at the system level to analyze a set of require- 
ments with respect to priority. Specifically, it is 
possible to re-prioritize this set of collection require- 
ments with respect to the current battlefield conditions 
rather than those which may have existed when the collection 
requirement was initially submitted for satisfaction by the 
user . 

This approach recognizes the fact that battlefield 
conditions change and that the relative importance of one 
requirement with respect to another might also change. In 
this study the battlefield conditions previously addressed 
will be referred to as battlefield parameters of interest or 
simply parameters. 
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1 he objective of this process is to rank all require- 
ments under consideration based upon one or several of the 
battlefield parameters of interest. In effect, this process 
provides the decision maker with a method of prioritizing 
requirements in accordance with the current or projected 
battlefield conditions. A multi-criteria aggregation scheme 
will be used to rank the set of collection requirements. 

A. I BE BEQOIREMENT BASKING MODEL 

The model for the requirement ranking process is 
described below: 

I 

MAXIMIZE: ^ w^Par^ 

k = 1 ~ ( e< 3 D A.1) 



i = The index for requirements, 

k = The index for parameters. 

1 = The total number of battlefield parameters. 

= Weighting associated with the kth parameter. 

par^y= The kth battlefield parameter associated with the 
ith requirement. 

There are a number of ways in which this scheme can be 
implemented through the specific allocation of weights to a 
particular set of parameters. 
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E. EATTIEF3ELD EAR A DETERS 

Ecar general battlefield parameters of interest will be 
addressed in this study. These four categories of parame- 
ters are net all inclusive. Virtually any parameter of 
interest to the unit cr command (depending upon the require- 
ment structure) could easily be substituted for or added to 
those addressed in the study. These are, however, represen- 
tative cf the basic concerns of battlefield decision makers. 

The first parameter addressed is the actual priority 
attached to the requirement. The requirement priority is 
provided by the user when it is initially submitted into the 
collection system for satisfaction. It will be assumed that 
priority reflects the importance of a requirement tc the 
user with respect to all other collection requirements 
submitted in accordance with the priority system (abuses of 
priority systems will not be addressed). For example, it 
will be assumed that all high priority requirements are of 
greater relative importance to all users than all medium 
priority requirements, etc. There are many different types 

cf priority systems in use. Most of these systems attempt 

to classify items in terms of levels of importance 
(priority). Such classification schemes can, in themselves, 
become complex. Only three levels of priority will be 
considered in this study - high, medium, and low. 

The friendly unit submitting the requirement is the 
second parameter of interest. As the battlefield changes, 
so dees the relative importance of friendly units. This 
importance is reflected in the amount of support a command 
receives from its parent and supporting units. This 
includes intelligence collection support. It is therefore 
important tc be able to reflect this changing importance 
when ranking collection requirements. The number and type 
of units included as varieties of this parameter are, of 
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Figure 1.1 Battlefield Areas. 

enemy activity. Maneuver units tend to be concerned with 
enemy maneuver and artillery forces, support units with 
special operation forces, headquarters elements with inter- 
diction targets and command and control operations. These 
concerns, of course, vary as the battlefield situation 
varies. Thus, timely control of the type of enemy activity 
the collection effort is directed against is valuable. For 
illustrative purposes the study considers four such classes 
of enemy activity - maneuver forces, artillery forces, 
support forces, and C3/other forces. Table II summarizes 
the major classes, levels, and subclasses of the fifteen 
parameters mentioned. 

C. BATTLEFIELD PABABETER 7 ALOES 

In this scheme two of the classes of parameters associated 
with a given reguirement have no particular values associ- 
ated with them other than presence or absence (with associ- 
ated values of either one or zero). For instance, 
reguirement can have either a high, medium, or low priority 
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TABLE II 

levels and Classes cf Bequirement Parameters 



CLASS LEVEL 



Priority High 

Mediu m 
Low 

Friendly User 



Battlefield Area 



Enemy Activity 



SUBCLASS 



Manuever Unit 1 
Maneuver Unit 2 
Artillery Unit 
Headquarters Element 



I 

II 

III 

IV 



Maneuver 
Artillery 
Support F 
C3/0ther 



Forces 

Forces 

orces 

Forces 



j 



This characteristic is also valid with respect to the 
friendly unit submitting the requirement. It does not 
necessarily apply to the parameter classes of battlefield 
area or type of enemy activity. It is conceivable in these 
cases that varying degrees of values could be associated 
with more than one parameter cf the class. For instance, a 
requirement regarding the communications capability cf an 
enemy artillery unit would fall into both the C3 and 
artillery parameter classes. Likewise, a requirement could 
easily be associated with more than one area of the 
battlefield. These sorts cf evaluations would be provided 
by the user and perhaps modified by the collection system 
operator with the aid of standard operating procedures. 
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WEIGHTING OF BATTLEFIELD P ABAMETE RS 



TABLE III 

Requirement Parameter Weighting Schemes 



PARAMETER 



I 



WEIGHTING SCHEMES 

II III IV 



Priority (h) .5 

Priority m) .3 

Priority (1) .2 

Onit 1 
Unit 2 
Arty Unit 
HQ Element 

Area I 
Area II 
Area III 
Area IV 

Maneuver Force 
Arty Force 
Support Force 
C 2/Ot her 



.2 



.3 

.3 

.2 



.2 

.2 



. 3 
.3 



. 2 

.2 



.3 
. 3 



Table III illustrates several battlefield parameter 
weighting schemes. Weighting scheme number I can be 
referred to as a standard scheme. The ranking of require- 
ments using this scheme is based solely upon the priority of 
the submitted requirements. Scheme number II can be 
referred to as a support scheme. Collection requirements 
will be ranked based upon the friendly unit submitting the 
requirement with seme emphasis placed upon priority. 
Specifically, maneuver unit number one and the artillery 
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unit are favored over the headquarters element. The K£ as, 
in turn, weighted egually with high priority requirements. 
The purpose behind this sort of weighting scheme would be to 
provide collection support to specific units because of 
their importance in relation to the current or projected 
battlefield situation. 

The last two weighting schemes are oriented towards 
targeting. Scheme III, for instance, is weighted to support 
requirements concerning enemy combat force targets (maneuver 
and artillery forces) near friendly forces (in battlefield 
areas I and II) . This scheme could be referred to as a 
direct support targeting scheme. Scheme IV, on the ether 
hand, is oriented towards targets in the enemy rear area 
(battlefield areas III and IV) and of a soft nature (C3 and 
Support Elements). This scheme could be referred to as an 
interdiction targeting scheme. If the decision maker were 
interested only in enemy artillery forces in battlefield 
area II then only these two parameters should be weighted 
(.5 in each case because there are two parameters of 
interest). If there exist such targets in the requirement 
set then they will be the highest ranking targets in the 
ordered requirement vector. 

The quantity, variety, and resolution levels of possible 
weighting schemes are uncountable. This methodology would 
be particularly useful to the decision maker in the event he 
was required to rank a large number of collection require- 
ments. 

E. AH EXAMPLE USING THE REQUIREMENT RANKING MODEL 

Table IV presents a set of twenty sample collection 
requirements which were generated to demonstrate the multi- 
criteria approach to collection requirement ranking. Note 
that in Table IV the values for the first two groups of 
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These requirements were place 
using the program REAEREQ. This 
which queries the operator for 
vector (Figure A. 2) . The input 
shown at Tatle V. 



d into an A?L usatle format 
is an interactive program 
a collection requirement 
values for this vector are 



v « 1 f-REflDREO ; v ; v i ; rho y s 
[ID vi«- i 16 />o 
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CIO] stop* 

Cl 13 RHO<-( It(fRM) ) -1 

C 1 23 RM«-(RHO, 16)f 

C 1 3 3 AifRM 
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Figure A. 2 Requirement Input Program READHEQ. 
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the same requirements which Ta-ble IV indicates have a 
priority of one. The next eight requirements (3 to 19) have 
a priority cf two and the last four (5 through 20) have a 
priority of three. In Scheme II the requirement order is 
based upon the unit submitting the requirement and the 
priority. A look at the higher ranking requirements associ- 
ated with Scheme II does indicate that they are a function 
cf being high priority and/or from Unit 1, the artillery 
unit or the headquarters element. Similar analysis of 
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Figure A. 3 Multi-Criteria Bequirement Banking Program. 



Schemes III and IV reveals that they do indeed rank the 
given set cf collection requirements in the manner suggested 
by their respective weighting schemes. Specifically, Scheme 
III is oriented towards enemy combat arms forces in the 
forward areas of the battlefield and Scheme IV is oriented 
towards support and C3 forces located in the rear areas of 
the battlefield. 

Cne additioral point for consideration regards the 
complexity of the requirement weighting schemes. This model 
will rank collection requirements according to even the most 
intricate of weighting schemes. It is difficult, however, 
to understand the output of such complicated schemes. 
Simple schemes are easy to check and also useful in sorting 
out a difficult collection management problem. This portion 
of the model is presented as a decision aid to allow for 
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TABLE 71 

Bequirement Banking with Weighting Schemes 
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improvement of current techniques in managing collection 
requirements which have traditionally employed FIFO (first 



130 



in first cut) methods. As such, it should be used to 
simplify the work of the decision maker rather than make it 
more difficult. 
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